Progress and error messages

Note: Progress messages, error messages, and empty LLM response handling all apply to regular (non-speech-to-speech) models. For speech-to-speech models, see Inactivity reminder.

Progress message

Sometimes it may take the Agent too much time to generate response, for example, due to use of multiple tools or slow tool response. In such cases, consider using 'Progress message' and 'Progress timeout' parameters in the Miscellaneous screen to define progress message that will be played to user while agent is “thinking”.

In addition to the time-based progress message described above, you can configure progress messages per tool — played before, on success, or on failure of that specific tool's execution — on the tool's Progress tab. See Tool progress messages.

Alternatively, you can play progress messages when specific tools are called using the legacy progress_message_conditions advanced configuration parameter. For details, see Conditional progress messages when calling tools.

How progress messages interact with the model's own speech

An agent has three ways to keep the user engaged while it works, and the framework coordinates them so it never talks over itself:

  1. the time-based progress message above (played when the whole turn is slow);
  2. per-tool messages — During execution / On success / On failure (see Tool progress messages);
  3. dynamic per-tool progress messages — the agent generates that tool's During execution line itself, based on the state of the conversation (see Letting the model write the message).

When the model speaks its own message alongside a (non-terminal) tool call, that message already fills the pre-tool wait, so the framework suppresses the redundant pre-tool reassurance for that step:

Everything else is unaffected: the tool's On success / On failure messages still play (they report the outcome, not the wait), and a different tool called later in the same turn — one with no accompanying message — still plays its own During execution message. Per-tool messages can play more than once per turn; the time-based message plays at most once.

Whether the model's message actually reaches the user on a non-streaming connection is controlled by the llm_message_with_tool_call advanced configuration parameter (play delivers it, drop discards it). With TTS streaming it is always delivered. If the message is dropped, nothing filled the wait, so the pre-tool reassurance is not suppressed.

Call-control tools. end_call and transfer_call are the exception. Any message the model wants spoken before hanging up or transferring comes from the tool's own termination_message / transfer_message parameters (not from llm_message_with_tool_call), and these tools end or transfer the turn — so they don't use the Before / On success / On failure progress scheme.

Error message

If Live Hub AI Agents Framework fails to receive valid response from LLM or encounters some other unexpected error, it generates “error response” to user. The default value for this response is “Sorry, I didn't get it. Can you please say it again?”

You may change the value by configuring ‘Error message’ parameter in the Miscellaneous tab, in the Agent configuration screen. For example:

Sorry, can you please rephrase your last question?

You can also customize the response provided to user when conversation is closed due to ‘Max turns’ configuration parameter. In order to do this, specify max_turns_message advanced configuration parameter:

{
    "max_turns_message": "Sorry, I need to hang up."
}

Empty LLM responses

Some LLMs may produce empty responses due to various technical issues or intermittent processing errors. By default AI Agents perform automatic retry upon empty LLM response, thus ensuring that conversation continues smoothly and user experience is not disrupted. You may change this behavior by configuring empty_llm_response advanced configuration parameter.

Parameter Type Description
empty_llm_response enum Configures how the AI Agent treats empty LLM response.
Supported values:
retry (default) – retry response generation; if response is still empty after the retry, treat it as an error
ignore – treat empty response as an error
allow – treat empty response as a valid response